Remote Library Loader for all the AcProtected programs

ARTeam Tutorial

Information	How to use ACProtected Programs legally and a little on code injection techniques on running processes.
Target	DummyApp compressed with AcProtect (SUPP, a freeware patching utility for Palm apps, inside this archive).
Available	http://www.BPVcentral.com
Tools	VisualStudio 6.0, AcProtect any version.
Protection	MessageBox
level	Medium on C++ and API calls
Category	Patching
Author	&8~) Shub-Nigurrath June 2004

1. Introduction

Hi all, today's problem is quite tricky and honestly just an excuse to introduce you on how processes injection works (just a technique).

The problem is quite simple: if you install AcProtect demo version it compress and obscure programs fully, but places an annoying messagebox (with an OK button) reminding that the program has been protected with an unregistered version of AcProtect. Let's call the AcProtected program ACP, so the problem is how to eliminate that annoying messagebox.
Reversing AcProtect is quite difficult, and anyway there's another way to eliminate the problem, being at the same time able to legally redistribute AcProtected programs and not being accused of piracy !!

The solution is quite simple too: load into the address space of the ACP program a DLL that intercepts automatically the MessageBox, press Ok for you and then go on to the program.

Moreover it's perfectly legal, because you're using a trial version of AcProtect and should work obviouslly for any future version.

Note that patching the Application, changing the Export Table (change the string MessageBox to GetMessage using an hex Editor), doesn't apply to our target (it works of course and it's a snap to do it, but isn't what we want). Consider this situation:

1. You're a little developer which do not want to spend resources licencing AcProtect and do not want to do something illegal.
2. you want to distribute a program protecting it a bit with AcProtect
3. you don't want to buy AcProtect (because you're a little developer)
4. you don't want to do something illegal (so AcProtect cracks are out of scope) and also any reverse engineering on the compressed code.
5. you don't want to bother users with the Nag that AcProtect places in programs protected with trial version.

The only available solution is the transparent interception of the dialog at runtime, and it's perfectly legal beause you haven't removed the nag at all, simply you have hidden it ;-)

I included partially an article from John Peroquin, which describes base principles of this tecquique.

2. Limitations

An important limitation is that to make this you need to write in the target process memory, using VirtualAllocEx and similar Win2000 and above only APIs. So this method works only for Windows2000/XP.

Note that there's also other solutions around, but aren't working, like Sunshine's one (http://www.sunshine2k.de/Tuts/tut_splasheasy.htm) because of AcProtect (it detects any modification to the executable's code and export table) -sic-

3. Description

This article describes the customization of existing applications through the use of custom Dynamic-Link Libraries (DLLs) and the process of, what can be called, Remote Library Loading. It also presents a small utility developed to make this process easier, titled the Remote Library Loader.

For the ideas here I give credit originally to Jeffrey Ricther in Programming Applications for Microsoft Windows with his "DLL Injection." and to John Peloquin for original post of part of this tutorial. The primary difference between our applications is that his works with running target processes, where this one also acts as a target process loader.

4. The problem

There is one major problem that arises when it comes to customizing existing applications: virtual address spaces. In 32-bit Windows environments, each application has its own virtual address space that only its components can see.

This means that one application cannot freely modify another without some additional work. This is the problem that is overcome with the Remote Library Loader and the use of custom DLLs. With the architecture described below, developers can work around this problem fairly easily, and accomplish their intended tasks.

The architecture developed to solve the problem above can be broken down into three discrete components. These components are as follows:

An existing target application that is to be customized
A created "plugin" DLL for customizing the target application
A loader application that is responsible for starting the target application and mapping the plugin DLL into its address space

We will now examine the second two components in detail. The target application will not be discussed here because its functionality is only pertinent to the plugin DLL developer, and could be one of many different things.

5. The Loader & The Plugin

The Loader
The loader component is provided to you as the Remote Library Loader. This executable acts as a controller and error-reporter for the entire architecture, and covers the basic tasks. Its tasks are as follows:

Start the target executable (using CreateProcess())
Allocate memory in target process address space (using VirtualAllocEx())
Copy the plugin DLL filename into remotely allocated memory (using WriteProcessMemory())
Create a thread in the target process which will call LoadLibrary() passing the plugin DLL filename stored earlier (using CreateRemoteThread())
Wait for this thread to finish (using WaitForSingleObject())
Free allocated memory in target process (using VirtualFreeEx())

If an error occurs during any one of the preceding steps, a message box is presented to the user, informing them of the error. This includes if the remote LoadLibrary() call fails to load the plugin DLL.

Please read the Readme.txt in the download package for specific information about loader installation/usage.

The Plugin
When the plugin DLL is loaded into the target process address space during the LoadLibrary() call, its entry-point function will be called. At this point, the DLL can perform initialization tasks and do whatever it wants to customize the application. The following model is recommended, for reasons I will explain:

Catch the DLL_PROCESS_ATTACH notification in the entry-point function.
On this notification, create a new thread (using CreateThread()).
Perform any and all customizations in this newly created thread.

It is important to follow this model for one main reason: Access to the entry-point function is serialized, meaning that it can be called only once at a time. Performing a lengthy operation in the DLL_PROCESS_ATTACH notification may force other threads attempting to call the entry-point function to wait, including threads within the target process (see Footnote #1). For this reason, use the model above for best performance.

Once in the newly created thread, customizations can be performed, such as subclassing one of the applications windows, and so forth, and other things that you can do in the context of the target process.

1. Here it is good to remember that newly created threads thread will attempt to call the entry-point function with a DLL_THREAD_ATTACH notification. But it is also important to note that even the target process primary thread may be affected when not using this model. The reason has to do with the functionality of CreateProcess() and LoadLibrary(). Because CreateProcess() can return before the target process primary thread has loaded all its required DLLs, it could still be calling LoadLibrary() even after the plugin DLL receives the DLL_PROCESS_ATTACH notification. If a lengthy operation prevents a return from this notification before another LoadLibrary() call occurs, that call will attempt to send a DLL_PROCESS_ATTACH notification. This then makes the primary thread waitg, which is certainly not desirable. So, for these two reasons it is important to use the recommended model for best results.

6. How to make it working

1. First step, place things in place:

Copy Loader.exe and your plugin DLL into the target application's directory (from folder Distribution)
Rename the target executable "Target.exe" (that should have been AcProtected of course)
Rename the plugin DLL "Plugin.dll"
Rename the Loader.exe as the original Application (so as the shortcuts will work)

2. Second step, running the target application

Run Loader.exe (or whatever is it's new name) when you want to run the target application.
Update any shortcuts on the start menu/desktop to do the same in case.

3. Third step, (eventually) uninstalling

Revert the target executable's filename to its original name.
Update any modified shortcuts on the start menu/desktop.

7. Conclusion

Sources are included into the distribution for any customization you would do. Do anything you want of them, but please mention me if you're going to redistribuite!

These are the folders contained into this archive:

Distribution: contains the files ready to be applied as in section 6 above
Example: contains a working example, try to launch Target.exe first of all and then SUPP.exe instead
Sources: contains the complete VC++ and ASM sources of the described components
Tutorial: contains this tutorial, but if you're reading me, you should already know ^__^

A BIG thanks goes to Peroquin and all ARTeam members
and all the other from who I have learnt so much as well as the crew on exetools & other places..
This tute would not have been possible without their hard work
and willingness to pass the knowledge on to others.

I hope someone may find this tut useful

Best Wishes

(.|.)
).( (¯`·._.·[¯¨´*·~-.¸¸,.-~*´¨&8~) Ŝħůβ¬Ňïĝµŕřāŧħ ₪ ¯¨´*·~-.¸¸,.-~*´¨]·._.·´¯)
( v )
\|/